home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 2001 May / SGI Freeware 2001 May - Disc 3.iso / dist / fw_squid.idb / usr / freeware / squid / doc / draft-vixie-icp-htcp-01.txt.z / draft-vixie-icp-htcp-01.txt
Text File  |  2000-04-13  |  31KB  |  794 lines
  1.  
  2.    ICP Working Group                                            Paul Vixie
  3.    INTERNET-DRAFT                                                      ISC
  4.    <draft-vixie-htcp-proto-04.txt>                           Duane Wessels
  5.                                                                      NLANR
  6.                                                                 June, 1999
  7.  
  8.  
  9.                     Hyper Text Caching Protocol (HTCP/0.0)
  10.  
  11.  
  12.    Status of this Memo
  13.  
  14.       This document is an Internet-Draft and is in full conformance with
  15.       all provisions of Section 10 of RFC2026.
  16.  
  17.       Internet-Drafts are working documents of the Internet Engineering
  18.       Task Force (IETF), its areas, and its working groups.  Note that
  19.       other groups may also distribute working documents as Internet-
  20.       Drafts.
  21.  
  22.       Internet-Drafts are draft documents valid for a maximum of six months
  23.       and may be updated, replaced, or obsoleted by other documents at any
  24.       time.  It is inappropriate to use Internet-Drafts as reference
  25.       material or to cite them other than as "work in progress."
  26.  
  27.       The list of current Internet-Drafts can be accessed at
  28.       http://www.ietf.org/ietf/1id-abstracts.txt
  29.  
  30.       The list of Internet-Draft Shadow Directories can be accessed at
  31.       http://www.ietf.org/shadow.html.
  32.  
  33.  
  34.    Abstract
  35.  
  36.       This document describes HTCP, a protocol for discovering HTTP caches
  37.       and cached data, managing sets of HTTP caches, and monitoring cache
  38.       activity.  This is an experimental protocol, one among several
  39.       proposals to perform these functions.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.    Expires December 1999                                           [Page 1]
  51.  
  52.    INTERNET-DRAFT                    HTCP                         June 1999
  53.  
  54.  
  55.    1 - Definitions, Rationale and Scope
  56.  
  57.    1.1. HTTP/1.1 (see [RFC2068]) permits the transfer of web objects from
  58.    ``origin servers'', possibly via ``proxies'' (which are allowed under
  59.    some circumstances to ``cache'' such objects for subsequent reuse) to
  60.    ``clients'' which consume the object in some way, usually by displaying
  61.    it as part of a ``web page.''  HTTP/1.0 and later permit ``headers'' to
  62.    be included in a request and/or a response, thus expanding upon the
  63.    HTTP/0.9 (and earlier) behaviour of specifying only a URI in the request
  64.    and offering only a body in the response.
  65.  
  66.    1.2. ICP (see [RFC2186]) permits caches to be queried as to their
  67.    content, usually by other caches who are hoping to avoid an expensive
  68.    fetch from a distant origin server.  ICP was designed with HTTP/0.9 in
  69.    mind, such that only the URI (without any headers) is used when
  70.    describing cached content, and the possibility of multiple compatible
  71.    bodies for the same URI had not yet been imagined.
  72.  
  73.    1.3. This document specifies a Hyper Text Caching Protocol (HTCP or
  74.    simply HoT CraP) which permits full request and response headers to be
  75.    used in cache management, and expands the domain of cache management to
  76.    include monitoring a remote cache's additions and deletions, requesting
  77.    immediate deletions, and sending hints about web objects such as the
  78.    third party locations of cacheable objects or the measured
  79.    uncacheability or unavailability of web objects.
  80.  
  81.    2 - HTCP Protocol
  82.  
  83.    2.1. All multi-octet HTCP protocol elements are transmitted in network
  84.    byte order.  All RESERVED fields should be set to binary zero by senders
  85.    and left unexamined by receivers.  Headers must be presented with the
  86.    CRLF line termination, as in HTTP.
  87.  
  88.    2.2. Any hostnames specified should be compatible between sender and
  89.    receiver, such that if a private naming scheme (such as HOSTS.TXT or
  90.    NIS) is in use, names depending on such schemes will only be sent to
  91.    HTCP neighbors who are known to participate in said schemes.  Raw
  92.    addresses (dotted quad IPv4, or colon-format IPv6) are universal, as are
  93.    public DNS names.  Use of private names or addresses will require
  94.    special operational care.
  95.  
  96.    2.3. UDP must be supported.  HTCP agents must not be isolated from
  97.    NETWORK failures and delays.  An HTCP agent should be prepared to act in
  98.    useful ways when no response is forthcoming, or when responses are
  99.    delayed or reordered or damaged.  TCP is optional and is expected to be
  100.  
  101.  
  102.  
  103.    Expires December 1999                                           [Page 2]
  104.  
  105.    INTERNET-DRAFT                    HTCP                         June 1999
  106.  
  107.  
  108.    used only for protocol debugging.  The IANA has assigned port 4827 as
  109.    the standard TCP and UDP port number for HTCP.
  110.  
  111.    2.4. A set of configuration variables concerning transport
  112.    characteristics should be maintained for each agent which is capable of
  113.    initiating HTCP transactions, perhaps with a set of per-agent global
  114.    defaults.  These variables are:
  115.  
  116.       Maximum number of unacknowledged transactions before a ``failure'' is
  117.       imputed.
  118.  
  119.       Maximum interval without a response to some transaction before a
  120.       ``failure'' is imputed.
  121.  
  122.       Should ICMP-Portunreach be treated as a failure?
  123.  
  124.       Should RESPONSE=5 && MO=1 be treated as a failure?
  125.  
  126.       Minimum interval before trying a new transaction after a failure
  127.  
  128.    2.5. An HTCP Message has the following general format:
  129.  
  130.       +---------------------+
  131.       |        HEADER       | tells message length and protocol versions
  132.       +---------------------+
  133.       |         DATA        | HTCP message (varies per major version number)
  134.       +---------------------+
  135.       |         AUTH        | optional authentication for transaction
  136.       +---------------------+
  137.  
  138.  
  139.    2.6. An HTCP/*.* HEADER has the following format:
  140.  
  141.                     +0 (MSB)                            +1 (LSB)
  142.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  143.       0: |                             LENGTH                            |
  144.          +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +
  145.       2: |                             LENGTH                            |
  146.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  147.       2: |             MAJOR             |             MINOR             |
  148.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.    Expires December 1999                                           [Page 3]
  157.  
  158.    INTERNET-DRAFT                    HTCP                         June 1999
  159.  
  160.  
  161.    LENGTH  is the message length, inclusive of all header and data octets,
  162.            including the LENGTH field itself.  This field will be equal to
  163.            the datagam payload size (``record length'') if a datagram
  164.            protocol is in use, and can include padding, i.e., not all
  165.            octets of the message need be used in the DATA and AUTH
  166.            sections.
  167.  
  168.    MAJOR   is the major version number (0 for this specification).  The
  169.            DATA section of an HTCP message need not be upward or downward
  170.            compatble between different major version numbers.
  171.  
  172.    MINOR   is the minor version number (0 for this specification).  Feature
  173.            levels and interpretation rules can vary depending on this
  174.            field, in particular RESERVED fields can take on new (though
  175.            optional) meaning in successive minor version numbers within the
  176.            same major version number.
  177.  
  178.    2.6.1. It is expected that an HTCP initiator will know the version
  179.    number of a prospective HTCP responder, or that the initiator will probe
  180.    using declining values for MINOR and MAJOR (beginning with the highest
  181.    locally supported value) and locally cache the probed version number of
  182.    the responder.
  183.  
  184.    2.6.2. Higher MAJOR numbers are to be preferred, as are higher MINOR
  185.    numbers within a particular MAJOR number.
  186.  
  187.    2.7. An HTCP/0.* DATA has the following structure:
  188.  
  189.                     +0 (MSB)                            +1 (LSB)
  190.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  191.       0: |                             LENGTH                            |
  192.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  193.       2: |    OPCODE     |   RESPONSE    |        RESERVED       |F1 |RR |
  194.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  195.       4: |                           TRANS-ID                            |
  196.          +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +
  197.       6: |                           TRANS-ID                            |
  198.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  199.       8: |                                                               |
  200.          /                            OP-DATA                            /
  201.          /                                                               /
  202.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.    Expires December 1999                                           [Page 4]
  210.  
  211.    INTERNET-DRAFT                    HTCP                         June 1999
  212.  
  213.  
  214.    LENGTH    is the number of octets of the message which are reserved for
  215.              the DATA section, including the LENGTH field itself.  This
  216.              number can include padding, i.e., not all octets reserved by
  217.              LENGTH need be used in OP-DATA.
  218.  
  219.    OPCODE    is the operation code of an HTCP transaction.  An HTCP
  220.              transaction can consist of multiple HTCP messages, e.g., a
  221.              request (sent by the initiator), or a response (sent by the
  222.              responder).
  223.  
  224.    RESPONSE  is a numeric code indicating the success or failure of a
  225.              transaction.  It should be set to zero (0) by requestors and
  226.              ignored by responders.  Each operation has its own set of
  227.              response codes, which are described later.  The overall
  228.              message has a set of response codes which are as follows:
  229.  
  230.              0   authentication wasn't used but is required
  231.              1   authentication was used but unsatisfactorily
  232.              2   opcode not implemented
  233.              3   major version not supported
  234.              4   minor version not supported (major version is ok)
  235.              5   inappropriate, disallowed, or undesirable opcode
  236.  
  237.              The above response codes all indicate errors and all depend
  238.              for their visibility on MO=1 (as specified below).
  239.  
  240.    RR        is a flag indicating whether this message is a request (0) or
  241.              response (1).
  242.  
  243.    F1        is overloaded such that it is used differently by requestors
  244.              than by responders.  If RR=0, then F1 is defined as RD.  If
  245.              RR=1, then F1 is defined as MO.
  246.  
  247.    RD        is a flag which if set to 1 means that a response is desired.
  248.              Some OPCODEs require RD to be set to 1 to be meaningful.
  249.  
  250.    MO        (em-oh) is a flag which indicates whether the RESPONSE code is
  251.              to be interpreted as a response to the overall message (fixed
  252.              fields in DATA or any field of AUTH) [MO=1] or as a response
  253.              to fields in the OP-DATA [MO=0].
  254.  
  255.    TRANS-ID  is a 32-bit value which when combined with the initiator's
  256.              network address, uniquely identifies this HTCP transaction.
  257.              Care should be taken not to reuse TRANS-ID's within the life-
  258.              time of a UDP datagram.
  259.  
  260.  
  261.  
  262.    Expires December 1999                                           [Page 5]
  263.  
  264.    INTERNET-DRAFT                    HTCP                         June 1999
  265.  
  266.  
  267.    OP-DATA   is opcode-dependent and is defined below, per opcode.
  268.  
  269.    2.8. An HTCP/0.0 AUTH has the following structure:
  270.  
  271.                     +0 (MSB)                            +1 (LSB)
  272.           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  273.        0: |                             LENGTH                            |
  274.           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  275.        2: |                            SIG-TIME                           |
  276.           +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +
  277.        4: |                            SIG-TIME                           |
  278.           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  279.        6: |                           SIG-EXPIRE                          |
  280.           +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +
  281.        8: |                           SIG-EXPIRE                          |
  282.           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  283.       10: |                                                               |
  284.           /                            KEY-NAME                           /
  285.           /                                                               /
  286.           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  287.        n: |                                                               |
  288.           /                            SIGNATURE                          /
  289.           /                                                               /
  290.           +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  291.  
  292.  
  293.    LENGTH      is the number of octets used by the AUTH, including the
  294.                LENGTH field itself.  If the optional AUTH is not being
  295.                transmitted, this field should be set to 2 (two).  LENGTH
  296.                can include padding, which means that not all octets
  297.                reserved by LENGTH will necessarily be consumed by
  298.                SIGNATURE.
  299.  
  300.    SIG-TIME    is an unsigned binary count of the number of seconds since
  301.                00:00:00 1-Jan-70 UTC at the time the SIGNATURE is
  302.                generated.
  303.  
  304.    SIG-EXPIRE  is an unsigned binary count of the number of seconds since
  305.                00:00:00 1-Jan-70 UTC at the time the SIGNATURE is
  306.                considered to have expired.
  307.  
  308.    KEY-NAME    is a COUNTSTR [3.1] which specifies the name of a shared
  309.                secret.  (Each HTCP implementation is expected to allow
  310.                configuration of several shared secrets, each of which will
  311.                have a name.)
  312.  
  313.  
  314.  
  315.    Expires December 1999                                           [Page 6]
  316.  
  317.    INTERNET-DRAFT                    HTCP                         June 1999
  318.  
  319.  
  320.    SIGNATURE   is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see
  321.                [RFC 2104]), with a B value of 64, of the following
  322.                elements, each of which is digested in its ``on the wire''
  323.                format, including transmitted padding if any is covered by a
  324.                field's associated LENGTH:
  325.  
  326.                IP SRC ADDR                           [4 octets]
  327.                IP SRC PORT                           [2 octets]
  328.                IP DST ADDR                           [4 octets]
  329.                IP DST PORT                           [2 octets]
  330.                HTCP MAJOR version number             [1 octet]
  331.                HTCP MINOR version number             [1 octet]
  332.                SIG-TIME                              [4 octets]
  333.                SIG-EXPIRE                            [4 octets]
  334.                HTCP DATA                             [variable]
  335.                KEY-NAME (the whole COUNTSTR [3.1])   [variable]
  336.  
  337.  
  338.    2.8.1. Shared secrets should be cryptorandomly generated and should be
  339.    at least a few hundred octets in size.
  340.  
  341.    3 - Data Types
  342.  
  343.    HTCP/0.* data types are defined as follows:
  344.  
  345.    3.1. COUNTSTR is a counted string whose format is:
  346.  
  347.                     +0 (MSB)                            +1 (LSB)
  348.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  349.       0: |                             LENGTH                            |
  350.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  351.       2: |                                                               |
  352.          /                              TEXT                             /
  353.          /                                                               /
  354.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  355.  
  356.  
  357.    LENGTH  is the number of octets which will follow in TEXT.  This field
  358.            is *not* self-inclusive as is the case with other HTCP LENGTH
  359.            fields.
  360.  
  361.    TEXT    is a stream of uninterpreted octets, usually ISO8859-1
  362.            ``characters''.
  363.  
  364.  
  365.  
  366.  
  367.  
  368.    Expires December 1999                                           [Page 7]
  369.  
  370.    INTERNET-DRAFT                    HTCP                         June 1999
  371.  
  372.  
  373.    3.2. SPECIFIER is used with the TST and CLR request messages, defined
  374.    below.  Its format is:
  375.  
  376.       +---------------------+
  377.       |        METHOD       | : COUNTSTR
  378.       +---------------------+
  379.       |         URI         | : COUNTSTR
  380.       +---------------------+
  381.       |       VERSION       | : COUNTSTR
  382.       +---------------------+
  383.       |       REQ-HDRS      | : COUNTSTR
  384.       +---------------------+
  385.  
  386.  
  387.    METHOD    (Since HTCP only returns headers, methods GET and HEAD are
  388.              equivilent.)
  389.  
  390.    URI       (If the URI is a URL, it should always include a ``:''<port>
  391.              specifier, but in its absense, port 80 should be imputed by a
  392.              receiver.)
  393.  
  394.    VERSION   is an entire HTTP version string such as ``HTTP/1.1''.
  395.              VERSION strings with prefixes other than ``HTTP/'' or with
  396.              version numbers less than ``1.1'' are outside the domain of
  397.              this specification.
  398.  
  399.    REQ-HDRS  are those presented by an HTTP initiator.  These headers
  400.              should include end-to-end but NOT hop-by-hop headers, and they
  401.              can be canonicalized (aggregation of ``Accept:'' is permitted,
  402.              for example.)
  403.  
  404.    3.3. DETAIL is used with the TST response message, defined below.  Its
  405.    format is:
  406.  
  407.       +---------------------+
  408.       |      RESP-HDRS      | : COUNTSTR
  409.       +---------------------+
  410.       |     ENTITY-HDRS     | : COUNTSTR
  411.       +---------------------+
  412.       |     CACHE-HDRS      | : COUNTSTR
  413.       +---------------------+
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.    Expires December 1999                                           [Page 8]
  422.  
  423.    INTERNET-DRAFT                    HTCP                         June 1999
  424.  
  425.  
  426.    3.4. IDENTITY is used with the MON request and SET response message,
  427.    defined below.  Its format is:
  428.  
  429.       +---------------------+
  430.       |      SPECIFIER      |
  431.       +---------------------+
  432.       |        DETAIL       |
  433.       +---------------------+
  434.  
  435.  
  436.    4 - Cache Headers
  437.  
  438.    HTCP/0.0 CACHE-HDRS consist of zero or more of the following headers:
  439.  
  440.    Cache-Vary: <header-name> ...
  441.       The sender of this header has learned that content varies on a set of
  442.       headers different from the set given in the object's Vary: header.
  443.       Cache-Vary:, if present, overrides the object's Vary: header.
  444.  
  445.    Cache-Location: <cache-hostname>:<port> ...
  446.       The sender of this header has learned of one or more proxy caches who
  447.       are holding a copy of this object.  Probing these caches with HTCP
  448.       may result in discovery of new, close-by (preferrable to current)
  449.       HTCP neighbors.
  450.  
  451.    Cache-Policy: [no-cache] [no-share] [no-cache-cookie]
  452.       The sender of this header has learned that the object's caching
  453.       policy has more detail than is given in its response headers.
  454.  
  455.       no-cache          means that it is uncacheable (no reason given),
  456.                         but may be shareable between simultaneous
  457.                         requestors.
  458.  
  459.       no-share          means that it is unshareable (no reason given),
  460.                         and per-requestor tunnelling is always required).
  461.  
  462.       no-cache-cookie   means that the content could change as a result of
  463.                         different, missing, or even random cookies being
  464.                         included in the request headers, and that caching
  465.                         is inadvisable.
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.    Expires December 1999                                           [Page 9]
  475.  
  476.    INTERNET-DRAFT                    HTCP                         June 1999
  477.  
  478.  
  479.    Cache-Flags: [incomplete]
  480.       The sender of this header has modified the object's caching policy
  481.       locally, such that requesters may need to treat this response
  482.       specially, i.e., not necessarily in accordance with the object's
  483.       actual policy.
  484.  
  485.       incomplete   means that the response headers and/or entity
  486.                    headers given in this response are not known to be
  487.                    complete, and may not be suitable for use as a
  488.                    cache key.
  489.  
  490.  
  491.    Cache-Expiry: <date>
  492.       The sender of this header has learned that this object should be
  493.       considered to have expired at a time different than that indicate by
  494.       its response headers.  The format is the same as HTTP/1.1 Expires:.
  495.  
  496.    Cache-MD5: <discovered content MD5>
  497.       The sender of this header has computed an MD5 checksum for this
  498.       object which is either different from that given in the object's
  499.       Content-MD5:  header, or is being supplied since the object has no
  500.       Content-MD5 header.  The format is the same as HTTP/1.1 Content-MD5:.
  501.  
  502.    Cache-to-Origin: <origin> <rtt> <samples> <hops>
  503.       The sender of this header has measured the round trip time to an
  504.       origin server (given as a hostname or literal address).  The <rtt> is
  505.       the average number of seconds, expressed as decimal ASCII with
  506.       arbitrary precision and no exponent.  <Samples> is the number of RTT
  507.       samples which have had input to this average.  <Hops> is the number
  508.       of routers between the cache and the origin, expressed as decimal
  509.       ASCII with arbitrary precision and no exponent, or 0 if the cache
  510.       doesn't know.
  511.  
  512.    6 - HTCP Operations
  513.  
  514.    HTCP/0.* opcodes and their respective OP-DATA are defined below:
  515.  
  516.    6.1. NOP (OPCODE 0):
  517.  
  518.    This is an HTCP-level ``ping.''  Responders are encouraged to process
  519.    NOP's with minimum delay since the requestor may be using the NOP RTT
  520.    (round trip time) for configuration or mapping purposes.  The RESPONSE
  521.    code for a NOP is always zero (0).  There is no OP-DATA for a NOP.  NOP
  522.    requests with RD=0 cause no processing to occur at all.
  523.  
  524.  
  525.  
  526.  
  527.    Expires December 1999                                          [Page 10]
  528.  
  529.    INTERNET-DRAFT                    HTCP                         June 1999
  530.  
  531.  
  532.    6.2. TST (OPCODE 1):
  533.  
  534.    Test for the presence of a specified content entity in a proxy cache.
  535.    TST requests with RD=0 cause no processing to occur at all.
  536.  
  537.    TST requests have the following OP-DATA:
  538.  
  539.                     +0 (MSB)                            +1 (LSB)
  540.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  541.       0: |                                                               |
  542.          /                          SPECIFIER                            /
  543.          /                                                               /
  544.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  545.  
  546.  
  547.    RESPONSE codes for TST are as follows:
  548.  
  549.    0   entity is present in responder's cache
  550.    1   entity is not present in responder's cache
  551.  
  552.    TST responses have the following OP-DATA, if RESPONSE is zero (0):
  553.  
  554.                     +0 (MSB)                            +1 (LSB)
  555.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  556.       0: |                                                               |
  557.          /                             DETAIL                            /
  558.          /                                                               /
  559.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  560.  
  561.    TST responses have the following OP-DATA, if RESPONSE is one (1):
  562.  
  563.                     +0 (MSB)                            +1 (LSB)
  564.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  565.       0: |                                                               |
  566.          /                           CACHE-HDRS                          /
  567.          /                                                               /
  568.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  569.  
  570.  
  571.    DETAIL  is a set of cache, entity, and response headers.  The cache
  572.            headers are described above.  Entity and response headers are
  573.            defined by HTTP.
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.    Expires December 1999                                          [Page 11]
  581.  
  582.    INTERNET-DRAFT                    HTCP                         June 1999
  583.  
  584.  
  585.    6.3. MON (OPCODE 2):
  586.  
  587.    Monitor activity in a proxy cache's local object store (adds, deletes,
  588.    replacements, etc).  Since interleaving of HTCP transaction over a
  589.    single pair of UDP endpoints is not supported, it is recommended that a
  590.    unique UDP endpoint be allocated by the requestor for each concurrent
  591.    MON request.  MON requests with RD=0 are equivilent to those with RD=1
  592.    and TIME=0; that is, they will cancel any outstanding MON transaction.
  593.  
  594.    MON requests have the following OP-DATA structure:
  595.  
  596.                      +0 (MSB)
  597.          +---+---+---+---+---+---+---+---+
  598.       0: |             TIME              |
  599.          +---+---+---+---+---+---+---+---+
  600.  
  601.  
  602.    TIME  is the number of seconds of monitoring output desired by the
  603.          initiator.  Subsequent MON requests from the same initiator with
  604.          the same TRANS-ID should update the time on a ongoing MON
  605.          transaction.  This is called ``overlapping renew.''
  606.  
  607.    RESPONSE codes for MON are as follows:
  608.  
  609.    0   accepted, OP-DATA is present and valid
  610.    1   refused (quota error -- too many MON's are active)
  611.  
  612.  
  613.    MON responses have the following OP-DATA structure, if RESPONSE is zero
  614.    (0):
  615.  
  616.                     +0 (MSB)                            +1 (LSB)
  617.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  618.       0: |             TIME              |     ACTION    |     REASON    |
  619.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  620.       2: |                                                               |
  621.          /                            IDENTITY                           /
  622.          /                                                               /
  623.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  624.  
  625.  
  626.    TIME      is the number of seconds remaining for this MON transaction.
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.    Expires December 1999                                          [Page 12]
  634.  
  635.    INTERNET-DRAFT                    HTCP                         June 1999
  636.  
  637.  
  638.    ACTION    is a numeric code indicating a cache population action.  Codes
  639.              are:
  640.  
  641.              0   an entity has been added to the cache
  642.              1   an entity in the cache has been refreshed
  643.              2   an entity in the cache has been replaced
  644.              3   an entity in the cache has been deleted
  645.  
  646.  
  647.    REASON    is a numeric code indicating the reason for an ACTION.  Codes
  648.              are:
  649.  
  650.              0   some reason not covered by the other REASON codes
  651.              1   a proxy client fetched this entity
  652.              2   a proxy client fetched with caching disallowed
  653.              3   the proxy server prefetched this entity
  654.              4   the entity expired, per its headers
  655.              5   the entity was purged due to caching storage limits
  656.  
  657.  
  658.    6.4. SET (OPCODE 3):
  659.  
  660.    Inform a cache of the identity of an object.  This is a ``push''
  661.    transaction, whereby cooperating caches can share information such as
  662.    updated Age/Date/Expires headers (which might result from an origin
  663.    ``304 Not modified'' HTTP response) or updated cache headers (which
  664.    might result from the discovery of non-authoritative ``vary'' conditions
  665.    or from learning of second or third party cache locations for this
  666.    entity.  RD is honoured.
  667.  
  668.    SET requests have the following OP-DATA structure:
  669.  
  670.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  671.       0: |                                                               |
  672.          /                            IDENTITY                           /
  673.          /                                                               /
  674.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  675.  
  676.  
  677.    RESPONSE  codes are as follows:
  678.  
  679.              0   identity accepted, thank you
  680.              1   identity ignored, no reason given, thank you
  681.  
  682.  
  683.  
  684.  
  685.  
  686.    Expires December 1999                                          [Page 13]
  687.  
  688.    INTERNET-DRAFT                    HTCP                         June 1999
  689.  
  690.  
  691.    SET responses have no OP-DATA.
  692.  
  693.    6.5. CLR (OPCODE 4):
  694.  
  695.    Tell a cache to completely forget about an entity.  RD is honoured.
  696.  
  697.    CLR requests have the following OP-DATA structure:
  698.  
  699.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  700.       0: |                   RESERVED                    |     REASON    |
  701.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  702.       2: |                                                               |
  703.          /                           SPECIFIER                           /
  704.          /                                                               /
  705.          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  706.  
  707.  
  708.    REASON    is a numeric code indicating the reason why the requestor is
  709.              asking that this entity be removed.  The codes are as follows:
  710.  
  711.              0   some reason not better specified by another code
  712.              1   the origin server told me that this entity does not exist
  713.  
  714.  
  715.    RESPONSE  codes are as follows:
  716.  
  717.              0   i had it, it's gone now
  718.              1   i had it, i'm keeping it, no reason given.
  719.              2   i didn't have it
  720.  
  721.  
  722.    CLR responses have no OP-DATA.
  723.  
  724.    Clearing a URI without specifying response, entity, or cache headers
  725.    means to clear all entities using that URI.
  726.  
  727.    7 - Security Considerations
  728.  
  729.    If the optional AUTH element is not used, it is possible for
  730.    unauthorized third parties to both view and modify a cache using the
  731.    HTCP protocol.
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.    Expires December 1999                                          [Page 14]
  740.  
  741.    INTERNET-DRAFT                    HTCP                         June 1999
  742.  
  743.  
  744.    8 - Acknowledgements
  745.  
  746.    Mattias Wingstedt of Idonex brought key insights to the development of
  747.    this protocol.  David Hankins helped clarify this document.
  748.  
  749.    9 - References
  750.  
  751.    [RFC1630]
  752.       T. Berners-Lee, ``Universal Resource Identifiers in WWW,'', RFC 1630,
  753.       CERN, June 1994.
  754.  
  755.    [RFC2068]
  756.       R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
  757.       ``Hypertext Transfer Protocol -- HTTP/1.1,'' RFC 2068, UC Irvine,
  758.       DEC, MIT/LCS, January 1997.
  759.  
  760.    [RFC2104]
  761.       H. Krawczyk, M. Bellare, R. Canetti, ``HMAC: Keyed-Hashing for
  762.       Message Authentication,'' RFC 2104, IBM and UCSD, February, 1997.
  763.  
  764.    [RFC2186]
  765.       D. Wessels, K. Claffy, ``Internet Cache Protocol (ICP), version 2,''
  766.       RFC 2186, National Laboratory for Applied Network Research/UCSD,
  767.       September 1997.
  768.  
  769.    10 - Author's Address
  770.  
  771.  
  772.       Paul Vixie
  773.          Internet Software Consortium
  774.          950 Charter Street
  775.          Redwood City, CA 94063
  776.          +1 650 779 7001
  777.          <vixie@isc.org>
  778.  
  779.  
  780.       Duane Wessels
  781.          National Lab for Applied Network Research
  782.          USCD, 9500 Gilman Drive
  783.          La Jolla, CA 92093
  784.          +1 303 497 1822
  785.          <wessels@nlanr.net>
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.    Expires December 1999                                          [Page 15]
  793.  
  794.